The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent the work is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
IEEE section 802.11, which is hereby incorporated by reference in its entirety, defines several different standards for configuring wireless Ethernet networks and devices. For example, 802.11 standards that have been popularized include 802.11, 802.11(a), 802.11(b), and 802.11(g). According to these standards, wireless network devices may be operated in either an infrastructure mode or an ad-hoc mode. In the infrastructure mode, the wireless network devices communicate with each other through an access point. In the ad-hoc mode, the wireless network devices (which are typically called stations or nodes) communicate directly with each other and do not employ an access point.
Referring now to FIG. 1, a wireless network 12 is shown that operates in an ad-hoc mode. The wireless network 12 includes multiple stations 14-1, 14-2, and 14-3 that transmit and receive wireless signals 16 directly with each other to form an ad-hoc network.
Power consumption of the stations is minimized to preserve battery life. To conserve power some stations implement a low-power mode in addition to an active mode. During the active mode, the stations transmit and/or receive data. During the low power mode, the stations may shut down components and/or alter operations. For example, stations may not transmit or receive data during the low-power mode. In wireless networks, stations typically are unable to remain in the low-power mode for a period of time that is sufficient to significantly reduce average power consumption.
In an ad-hoc network, a beacon is generated each beacon interval by one of the stations in that network. Each beacon interval has an associated announcement traffic indication map (ATIM) window and data transmission window. Each station remains awake after each beacon for at least the duration of the ATIM window.
An ATIM frame is transmitted during the ATIM window to indicate that a station has buffered packets for another station. Multiple stations may transmit ATIM frames during the ATIM window. In addition, there may be multicast ATIM messages that need to be sent during the ATIM window. When a station receives an ATIM frame during the ATIM window, the station remains awake for the entire beacon interval.
The length of the ATIM window is set at the time a wireless network is created by an ad-hoc creator. The ad-hoc creator may refer to a user or alternatively may refer to a station that is first to enter and/or create the network. The ATIM window may be sub-optimal. In other words, the ATIM window may be too long or too short depending upon a number of currently active conversations between stations. An active conversation refers to a communication session between two or more stations.
An ATIM window that is too long leads to a shorter effective data exchange window, which in turn leads to lower data throughput for a given beacon interval. An ATIM window that is too long also results in sub-optimal power savings since the amount of time the stations are in an awake state increases.
An ATIM window that is too short leads to longer latencies and/or packet loss. An ATIM frame is transmitted for each active conversation. Each ATIM frame is associated with a different active conversation and has a corresponding transmission and acknowledgement period. The transmission and acknowledgement periods may not overlap in time. Thus, one or more ATIM frames and/or corresponding acknowledgements may not be transmitted during an ATIM window when an increased number of ATIM frames are to be transmitted. The ATIM frames and acknowledgements that do not get transmitted in a first ATIM window or beacon interval are delayed and transmitted along with their corresponding data packets during subsequent beacon intervals. This can result in a backlog of ATIM frames and/or data packets.